Summary

Begin Pulse Gates feature by updating the schema. Calibrations may be in the job config or the experiment config.

Example:

// job: QasmQobj
// job.config
{
  'pulse_library': [
    // same as pulse lib for PulseQobj
  ],
  'calibrations': {'gates': [
      // see below
    ],
  }
}

// job.experiments[0].config.calibrations
{
  'gates: [
    {"name": "rxtheta", "qubits": [0], "params": [3.14], "instructions": [openpulse_instructions]},
    {"name": "rxtheta", "qubits": [0], "params": [1.57], "instructions": [openpulse_instructions]},
    {"name": "rxtheta", "qubits": [1], "params": [1.57], "instructions": [openpulse_instructions]}
  ]
}

The 'gates' information must be sufficient to match against any QASM Qobj instruction within the job.experiments[i].instructions fields, for instance: QasmQobjInstruction(name='rxtheta', params=[1.57], qubits=[1]) matches the last entry.

We can move pulse_library to the top level to avoid duplicating memory-intensive pulse waveforms in a single job. The assembler will assert that each waveform in the pulse library is referenced uniquely.

Details and comments

• TODO: add an example json
• TODO: GateCalibration object
• TODO: Move pulse_library to qobj level
• TODO: add qobj.config.calibrations field
• Update example json with some top level calibrations

Limitations

The current iteration supports any possible job, however, it is of course less efficient than a parameterized Qobj would be.

This schema cannot support unbound parameters, which is also true for any circuit at the moment, except here: Qiskit/qiskit-aer#485. Supporting unbound parameters should be done in a follow up (e.g., a gate's params are not fully specified and a value in the openpulse_instructions depends on that param). This follow up should be useable/compatible with Pulse Schedule, as well.